Performance-Optimierung

• Verwenden Sie keine gemeinsamen Caches für die Prozessorkerne Ihrer Steuerung.

• Verwenden Sie für Ihr Zielgerät einen physikalischen Adapter für ethernet-basierte Feldbusse, wenn Sie diese einsetzen. Verwenden Sie keine Switch-Architektur.

• Verwenden Sie einen Echtzeit-Kernel.

  Wir empfehlen die Verwendung des RT-Preempt-Kernels (https://rt.wiki.kernel.org) für Ihr Linux-System. Bei Debian- / Ubuntu-Distributionen finden Sie einen RT-Kernel als Package, das Sie einfach über apt installieren können. Details dazu finden Sie im Handbuch Ihrer Distribution.

  • Auf Debian-Systemen

    sudo apt-get install linux-image-rt-amd64

  • Überprüfung, welchen Kernel Sie verwenden, beispielsweise mit dem Befehl uname -a.

• Vermeiden Sie die Verwendung eines Window-Managers, GUI/X-Servers oder Ähnliches auf Ihrem System.

  Die Verwendung der genannten Tools wird die Echtzeitfähigkeiten Ihres Systems beeinträchtigen, was zu einem hohen Jitter bei der IEC-Anwendung führt.

Verwendung von "rt-tools":

• Installieren von "rt-tools" : sudo apt install rt-tests

• Starten von "cyclictest" : sudo cyclictest -p 99 -t -m

• Der Befehl man cyclictest zeigt Ihnen weitere Kommandozeilenoptionen, mit denen Sie mehr oder bestimmte Leistungsaspekte Ihres Systems besser messen können.

• Deaktivieren Sie den CPU-Energiesparmodus.

• Deaktivieren Sie Hyperthreading.

  Sie können das Hyperthreading beispielsweise mit folgendem Befehl deaktivieren:

  echo off | sudo tee /sys/devices/system/cpu/smt/control

• Deaktivieren Sie CPU-Frequenzskalierung und -Umschaltung so weit wie möglich.

  Setzen Sie beispielsweise die minimale und maximale CPU-Frequenz auf denselben (festen) Wert.

• Deaktivieren Sie den RealTime-Throttling-Mechanismus des Linux-Kernels, da dieser zu Jitter auf Ihrem System führen kann.

  Für weitere Informationen siehe: The Linux Foundation: Scheduling - RT Throttling

  Sie können das RealTime-Throttling beispielsweise mit folgendem Befehl deaktivieren:

  echo -1 > /proc/sys/kernel/sched_rt_runtime_us

• Prüfen und ändern Sie den Scheduling/Scaling Governor.

  • Prüfen des verwendeten Scheduling/Scaling Governor:

    cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

  • Ändern des verwendeten Scheduling/Scaling Governors (als root/admin) auf Performance:

    echo "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
    # set it for all available cores:
    echo "performance" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
    echo "performance" > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor
    echo "performance" > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor

    Beachten Sie, dass der Scaling Governor nach jedem Systemstart neu gesetzt werden muss. Sie können ihn auch über die Kernelkonfiguration setzen.

    Der Kerneltreiber intel_pstate kann die korrekte Einstellung erschweren. Überprüfen Sie deshalb Ihre Konfiguration mit dem Befehl cpufreq-info.

  • Sie können auch Programme wie cpu-freq-utils verwenden. Dies könnte mit den Intel-Pstate-Treibern interferieren. Diese Treiber benötigen normalerweise einen anderen Ansatz, um die CPU-Frequenz festzulegen.

  • Für weitere Informationen siehe https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt

• Deaktivieren Sie im Bios HyperV, falls verfügbar.

• Erstellen Sie eine Testanwendung, die in etwa die Anwendung beschreibt, für die Sie Ihr System optimieren möchten (in Bezug auf benötigte Ressourcen, erforderliche Leistung und Projektgröße).

• Sie können dies iterativ tun: Erstellen Sie zunächst eine sehr grobe Annäherung und erweitern Sie diese dann, um der tatsächlichen Applikation immer näher zu kommen.

• Min. Jitter (µs) / Max. Jitter (µs)

  • Die Werte sollten so nah wie möglich an den Werten liegen, die durch das Programm "cycletest" ermittelt wurden. Details dazu sind im Abschnitt Einrichten von Linux beschrieben.

  • Für weitere Informationen bezüglich Jitter und Latenz siehe: Definitionen Jitter, Latenz

  • Für weitere Informationen zur Registerkarte Überwachung siehe: Registerkarte: Überwachung

• Durchschnittliche Zykluszeit (µs) / Max. Zykluszeit (µs)

  • Der maximale Zyklus sollte nie in die Nähe der konfigurierten Zyklusdauer kommen. Dies führt zu Problemen, sobald das System eine hohe Last erfährt.

  • Halten Sie die Zykluszeit generell immer so niedrig wie möglich.

• Splitten Sie lang laufende Tasks in mehrere kleinere Tasks.

• Während des Betriebs sollte die maximale Zykluszeit der höchstpriorisierten Task niemals die konfigurierte Zykluszeit erreichen. Wenn Sie dies nicht vermeiden können, sollten Sie die konfigurierte Zykluszeit erhöhen, um konsistente Ausführungszeiten zu gewährleisten.

• Beim Start von Feldbussystemen (beispielsweise EtherCAT / PROFINET) kann es durch die Startzyklen zu einer etwas höheren CPU-Last kommen. Für diesen Fall ist es sinnvoll, die CPU-Last kurz nach dem Start der Applikation zu überwachen.

Die folgenden Optionen können nicht in CODESYS Virtual Control SL geändert werden, sondern müssen auf dem Host konfiguriert werden:

• Setzen Sie den Wert für DisableCpuDmaLatency auf 1:

  [SysCpuHandling]
  Linux.DisableCpuDmaLatency=1

  • Beachten Sie, dass dies die Standardeinstellung ab Laufzeitversion 4.11.0.0 ist.

  • Sie können Ihre Laufzeitversion über den Befehl Extras → Linux aktualisieren → System → System-Info überprüfen.

• Prüfen Sie, ob der Echtzeit-Kernel wirklich verwendet wird.

  • Ab Version 4.11.0.0 können Sie den SPS-Shell-Befehl rt-get kernelinfo verwenden, um dies zu überprüfen.

  • Wenn Sie eine ältere Version haben, können Sie dies direkt auf der Kommandozeile mit dem Befehl uname -a.

  • Wenn der Echtzeit-Kernel nicht verwendet wird, müssen Sie von Grund auf neu starten.

• Sie können die Tests aus dem vorherigen Schritt Konfigurieren des CODESYS-Laufzeitsystems verwenden, um Ihre IEC-Anwendung zu testen.

• Sie können das Multicore-Feature in CODESYS nutzen.

• Legen Sie die richtigen Prioritäten für Ihre Tasks fest. Wichtige Tasks sollten eine höhere Priorität haben.

  Tabelle 5. Zuordnung von IEC-Task-Prioritäten und Linux-Thread-Prioritäten:

  IEC-Taskpriorität	Linux-Priorität
  --	88 (SCHED_FIFO)
  --	57 (SCHED_FIFO)
  0 (höchste Echtzeit Prio)	56 (SCHED_FIFO)
  15 (niedrigste Echtzeit Prio)	41 (SCHED_FIFO)
  16 (nicht Echtzeit Prio)	0 (SCHED_OTHER)
  31 (nicht Echtzeit Prio)	0 (SCHED_OTHER)
  --	0 (SCHED_OTHER)
  Hinweis Auf einem herkömmlichen Linuxsystem befinden sich die meisten Interrupts (IRQs) und Kernel-Worker auf Linux-Priorität 50. Das Verwenden von Prioritäten (mit hoher Last) oberhalb kann dazu führen, dass Systemfunktionen (Netzwerk/Speicher) nicht wie gewünscht funktionieren.

  
  
  

• Sie können die Priorität einer Task in der jeweiligen Taskkonfiguration konfigurieren.

  

Wenn Sie nach allen hier genannten Schritten nicht die gewünschte Performance erreichen, können Sie einen Blick auf die folgenden Abschnitte werfen:

• Feldbus-spezifische Informationen

• [Für Experten] - Zusätzliche Tools und Themen

• Überprüfen Sie die Werte Send Time / Recv Time auf der EtherCAT-Statusseite

  • Eine x64 CPU mit einem Intel Core i7-Prozessor und einem guten Adapter sollte weniger als 10µs haben.

  • ARM-Prozessoren mit integriertem Chip werden ~50µs oder mehr haben.

  

• Überprüfen Sie die Werte Send Time / Recv Time auf der PROFINET-Statusseite.

  • Eine x64 CPU mit einem Intel Core i7-Prozessor und einem guten Adapter sollte weniger als 10µs haben.

  • ARM-Prozessoren mit integriertem Chip werden ~50µs oder mehr haben.

  

• Um Ihre Prioritäten und benötigten IRQs zu sortieren, können Sie die SPS-Shell-Befehle irq-list und irq-set-prio verwenden.

  • Diese Befehle verwenden die normalen Linux-Prioritäten und nicht die IEC-Prioritäten.

  • Diese Optimierung ist nicht in CODESYS Virtual Control SL möglich, sondern auf dem Host-System.

• Verwenden Sie einen eigenen/separaten Netzwerkadapter für die Geräte.

• Für weitere Informationen siehe:

  • EtherCAT

  • PROFINET

  • Ethernet/IP

  • CANbus, CANopen

• Kernelshark / Kernel-Trace

  • Dies ist das Programm Ihrer Wahl, wenn Sie feststellen, dass die Ursache für Ihre Performance-Probleme im Scheduling liegt. Mit Hilfe von "Kernel-Trace" können Sie sehen, ob Ihre Task durch eine andere Task, durch einen anderen Dienst oder einen Interrupt unterbrochen wird.

    • trace-cmd record -p function

    • Sie können Kernelshark verwenden, um die erzeugte Datei trace.dat zu untersuchen.

  • Im Allgemeinen lassen sich die Probleme beim Scheduling in zwei Kategorien einteilen:

    • Supersession / preemption

      • Wenn der Interrupt oder die Task, die Ihre Ausführung verhindert, unnötig ist, deaktivieren Sie diese.

      • Erhöhen Sie die Priorität Ihrer Task oder verringern Sie die der anderen.

      • Wechseln Sie zu einem anderen CPU-Kern.

      Wichtig

      Überprüfen Sie die Wirksamkeit der Änderungen mit Hilfe der im vorigen Kapitel beschriebenen Programme.

    • Execution time

      Siehe nachfolgend "Kernel-functiontrace"

• Kernel-functiontrace

  • Wenn Sie feststellen, dass die Code-Ausführungszeit zu hoch ist, können Sie dieses Tool verwenden, um das Problem zu lokalisieren.

  • Wenn die Funktion mit zu hoher Ausführungszeit in Ihrem eigenem Code liegt, müssen Sie ihn optimieren.

  • Wenn sich die Funktion mit zu hoher Ausführungszeit im Kernel befindet, können Sie versuchen, die gewünschte Funktionaliät mit einer anderen Kernel-Funktion zu erreichen. Alternativ können Sie dem Kernel-Treiber möglicherweise Konfigurationsparameter übergeben, um die Ausführungszeit zu verringern.

  • Wenn keine dieser Optionen das Problem löst, müssen Sie wahrscheinlich eine leistungsstärkere Hardware einsetzen.

Schauen Sie sich die folgenden Punkte an und prüfen Sie, ob sie das richtige Instrument sind, um Ihre Performance-Ziele zu erreichen:

• PREEMPT_FULL

• isolcpu

• rcu_nocbs

• rcu_nocb_poll

• nosoftlockup

• irqbalance disable

• kernel.sched_rt_runtime_us